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Abstract 


This memo describes the interface to the IBM 5250 Telnet server that 
allows client Telnet to request a Telnet terminal or printer session 
using a specific device name. If a requested device name is not 
available, a method to retry the request using a new device name is 
described. Methods to request specific Telnet session settings and 
auto-signon function are also described. 


By allowing a Telnet client to select the device name, the 5250 
Telnet server opens the door for applications to set and/or extract 
useful information about the Telnet client. Some possibilities are 
1) selecting a customized device name associated with a particular 
user profile name for National Language Support or subsystem routing, 
2) connecting PC and network printers as clients and 3) auto-signon 
using clear-text or DES-encrypted password exchange. 


Applications may need to use system API's on the AS/400 in order to 
extract Telnet session settings from the device name description. 
Refer to the Retrieve Device Description (QDCRDEVD) API described in 
the AS/400 System API book [3] on how to extract information using 
the DEVD0600 and DEVD1100 templates. 


This memo describes how the IBM 5250 Telnet server supports Work 
Station Function (WSF) printers using 5250 Display Station Pass- 
Through. A response code is returned by the Telnet server to 
indicate success or failure of the WSF printer session. 
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1. Enhancing Telnet Negotiations 


The 5250 Telnet server enables clients to negotiate both terminal and 
printer device names through Telnet Environment Options Negotiations, 
defined in the Standards Track RFC 1572 [13]. 


The purpose of RFC 1572 is to exchange environment information using 
a set of standard or custom variables. By using a combination of 
both standard VAR's and custom USERVAR's, the 5250 Telnet server 
allows client Telnet to request a pre-defined specific device by 
name. 


If no pre-defined device exists then the device will be created, with 
client Telnet having the option to negotiate device attributes, such 
as the code page, character set, keyboard type, etc. 


Since printers can now be negotiated as a device name, new terminal 
types have been defined to request printers. For example, you can 
now negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE 
options [11]. 


Finally, the 5250 Telnet server will allow exchange of user profile 
and password information, where the password may be in either clear- 
text or encrypted form. If a valid combination of profile and 
password is received, then the client is allowed to bypass the sign- 
on panel. The setting of the ORMTSIGN system value must be either 
*VERIFY or *SAMEPRF for the bypass of the sign-on panel to succeed. 


2. Standard Telnet Option Negotiation 


Telnet server option negotiation typically begins with the issuance, 
by the server, of an invitation to engage in terminal type 
negotiation with the Telnet client (DO TERMINAL-TYPE) [11]. The 
client and server then enter into a series of sub-negotiations to 
determine the level of terminal support that will be used. After the 
terminal type is agreed upon, the client and server will normally 
negotiate a required set of additional options (EOR [12], BINARY 
[10], SGA [15]) that are required to support "transparent mode" or 
full screen 5250/3270 block mode support. As soon as the required 
options have been negotiated, the server will suspend further 
negotiations, and begin with initializing the actual virtual device 
on the AS/400. A typical exchange might start like the following: 
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AS/400 Telnet server Enhanced Telnet client 
IAC DO TERMINAL-TYPE --> 

<-- TAC WILL TERMINAL-TYPE 
TAC SB TERMINAL-TYPE SEND 
TAC SE --> 

TAC SB TERMINAL-TYPE IS 

<-- IBM-5555-C01 IAC SE 
IAC DO EOR --> 

<-- TAC WILL EOR 

<-- IAC DO EOR 
IAC WILL EOR --> 


(other negotiations) 


Actual bytes transmitted in the above example are shown in hex below. 


AS/400 Telnet server Enhanced Telnet client 
FF FD 18 --> 

<-- FF FB 18 
FF FA 18 01 FF FO --> 


FF FA 18 00 49 42 4D 2D 
35 35 35 35 2D 43 30 31 


<-- FF FO 
FF FD 19 --> 
«-- FF FB 19 
«-- FF FD 19 
FF FB 19 --> 


(other negotiations) 


Some negotiations are symmetrical between client and server and some 
are negotiated in one direction only. Also, it is permissible and 
common practice to bundle more than one response or request, or 
combine a request with a response, so the actual exchange may look 
different in practice to what is shown above. 


3. Enhanced Telnet Option Negotiation 
In order to accommodate the new environment option negotiations, the 


server will bundle an environment option invitation along with the 
standard terminal type invitation request to the client. 
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A client should either send a negative acknowledgment 
or at some point after completing terminal-type 
but before completing the full set of negotiations 
engage in environment option 
A maximum of 1024 bytes of 

A recommended 


ENVIRON), 
negotiations, 


required for 5250 transparent mode, 
sub-negotiation with the server. 
environment strings may be sent to the server. 
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sequence might look like the following: 


AS/400 Telnet server 


IAC DO NEW-ENVIRON 
IAC DO TERMINAL-TYPE 
(2 requests bundled) 


IAC SB NEW-ENVIRON SEND 
VAR IAC SE 


IAC SB TERMINAL-TYPE SEND 
IAC SE 


IAC DO EOR 

(server will continue 
with normal transparent 
mode negotiations) 


(other negotiations) 


Actual bytes transmitted in 


AS/400 Telnet server 


(2 requests bundled) 


FA 27 01 00 FF F0 
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(WONT NEW- 


--> 

<-- IAC WILL NEW-ENVIRON 

--> 
IAC SB NEW-ENVIRON IS 
VAR "USER" VALUE "JONES" 
USERVAR "DEVNAME" 
VALUE "MYDEVICEO7" 

<-- IAC SE 

<-- IAC WILL TERMINAL-TYPE 
(do the terminal type 
sequence first) 

--> 
IAC SB TERMINAL-TYPE IS 

<-- IBM-5555-CO1 IAC SE 
(terminal type negotiations 
completed) 

--> 

<-- IAC WILL EOR 

the above example are shown in hex below. 
Enhanced Telnet client 

--> 

<-- FF FB 27 

--> 
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FF FA 27 00 00 55 53 45 
52 01 4A 4F 4E 45 53 03 
44 45 56 4E 41 4D 45 01 
4D 59 44 45 56 49 43 45 
<-- 30 37 FF FO 
<-- FF FB 18 
(do the terminal type 
sequence first) 


FF FA 18 01 FF FO --> 
FF FA 18 00 49 42 4D 2D 
35 35 35 35 2D 43 30 31 
«-- FF FO 
FF FD 19 --» 


(server will continue 
with normal transparent 
mode negotiations) 
<-- FF FB 19 


(other negotiations) 


RFC 1572 defines 6 standard VAR’s: USER, JOB, ACCT, PRINTER, 
SYSTEMTYPE, and DISPLAY. The USER standard VAR will hold the value 
of the AS/400 user profile name to be used in auto-signon requests. 
The Telnet server will make no direct use of the additional 5 VAR's, 
nor are any of them required to be sent. All standard VAR's and 
their values that are received by the Telnet server will be placed in 
a buffer, along with any USERVAR's received (described below), and 
made available to a registered initialization exit program to be used 
for any purpose desired. 


There are some reasons you may want to send NEW-ENVIRON negotiations 
prior to TERMINAL-TYPE negotiations. With AS/400 TELNET server, 
several virtual device modes can be negotiated: 1) VTxxx device 2) 
3270 device 3) 5250 device (includes Network Station). The virtual 
device mode selected depends on the TERMINAL-TYPE negotiated plus any 
other TELNET option negotiations necessary to support those modes. 
The AS/400 TELNET server will create the desired virtual device at 
the first opportunity it thinks it has all the requested attributes 
needed to create the device. This can be as early as completion of 
the TERMINAL-TYPE negotiations. 


For the case of Transparent mode (5250 device), then the moment 
TERMINAL-TYPE, BINARY, and EOR options are negotiated the TELNET 
server will go create the virtual device. Receiving any NEW-ENVIRON 
negotiations after these option negotiations are complete will result 
in the NEW-ENVIRON negotiations having no effect on device 
attributes, as the virtual device will have already been created. 
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So, for Transparent mode, NEW-ENVIRON negotiations are effectively 
closed once EOR is negotiated, since EOR is generally the last option 
done. 


For other devices modes (such as VTxxx or 3270), you cannot be sure 
when the AS/400 TELNET server thinks it has all the attributes to 
create the device. Recall that NEW-ENVIRON negotiations are 
optional, and therefore the AS/400 TELNET server need not wait for 
any NEW-ENVIRON options prior to creating the virtual device. It is 
in the clients best interest to send NEW-ENVIRON negotiations as soon 
as possible, preferably before TERMINAL-TYPE is negotiated. That 
way, the client can be sure the requested attributes were received 
before the virtual device is created. 


4. Enhanced Display Emulation Support 


RFC 1572 style USERVAR variables have been defined to allow a 
compliant Telnet client more control over the Telnet server virtual 
device on the AS/400. These USERVAR's allow the client Telnet to 
create or select a previously created virtual device. If the virtual 
device does not exist and must be created, then the USERVAR variables 
are used to create and initialize the device attributes. If the 
virtual device already exists, the device attributes are modified. 


The USERVAR's defined to accomplish this are: 


USERVAR VALUE EXAMPLE DESCRIPTION 

DEVNAME us-ascii char (x) MYDEVICEO7 Display device name 
KBDTYPE us-ascii char (3) USB Keyboard type 
CODEPAGE us-ascii char(y) 437 Code page 

CHARSET us-ascii char(y) 1212 Character set 


x - up to a maximum of 10 characters 
y - up to a maximum of 5 characters 


For a description of the KBDTYPE, CODEPAGE and CHARSET parameters and 
their permissible values, refer to Chapter 8 in the Communications 
Configuration Reference [5] and also to Appendix C in National 
Language Support [16]. 


The CODEPAGE and CHARSET USERVAR's must be associated with a KBDTYPE 
USERVAR. If either CODEPAGE or CHARSET are sent without KBDTYPE, 
they will default to system values. A default value for KBDTYPE can 
be sent to force CODEPAGE and CHARSET values to be used. 
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AS/400 system objects such as device names, user profiles, clear-text 
passwords, programs, libraries, etc. are required to be specified in 
English Upper Case (EUC). This includes: 


Any letter (A-Z), any number (0-9), special characters (4 $ _ Q) 


Therefore, where us-ascii is specified for VAR or USERVAR values, it 
is recommended that upper-cased ASCII values be sent, which will be 
converted to EBCDIC by the Telnet server. 


A special case occurs for encrypted passwords (described in the next 
section), where both the initial password and user profile used to 
build the encrypted password must be EBCDIC English Upper Case, in 
order to be properly authenticated by the Telnet server. 


5. Enhanced Display Auto-Signon and Password Encryption 


Several 5250 Telnet server specific USERVAR's will be defined. One 
will carry a random seed to be used in Data Encryption Standard (DES) 
password encryption, and another will carry the encrypted copy of the 
password. This would use the same 7-step DES-based password 
substitution scheme as APPC and Client Access. For a description of 
DES encryption, refer to Federal Information Processing Standards 
Publications (FIPS) 46-2 [17] and 81 [18], which can be found at the 
Federal Information Processing Standards Publications link: 


http://www.itl.nist.gov/div897/pubs/by-num.htm 


For a description of the 7-step password substitution scheme, refer 
to these IBM Customer Support FTP Server links: 


ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps 
ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps.Z 
ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.zip 


If encrypted password exchange is not required, clear-text password 
exchange is permitted using the same USERVAR's defined for 

encryption. For this case, the random client seed should be set to 
either an empty value (RFC 1572 preferred method) or to hexadecimal 
zeros to indicate the password is not encrypted, but is clear-text. 


It should be noted that security of clear-text password exchange 
cannot be guaranteed unless the network is physically protected or a 
trusted network (such as an intranet). If your network is vulnerable 
to IP address spoofing or directly connected to the Internet, you 
should engage in encrypted password exchange to validate a clients 
identity. 
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Additional VAR's and USERVAR's have also been defined to allow an 
auto-signon user greater control over their startup environment, 
similar to what is supported using the Open Virtual Terminal 
(QTVOPNVT) API [3]. 


The standard VAR’s supported to accomplish this are: 
VAR VALUE EXAMPLE DESCRIPTION 
USER us-ascii char (x) USERXYZ User profile name 


x - up to a maximum of 10 characters 


The custom USERVAR's defined to accomplish this are: 


USERVAR VALUE EXAMPLE DESCRIPTION 
IBMRSEED binary (8) 8-byte hex field Random client seed 
IBMSUBSPW binary (10) 10-byte hex field Substitute password 
IBMCURLIB us-ascii char (x) QGPL Current library 
IBMIMENU us-ascii char (x) MAIN Initial menu 
IBMPROGRAM us-ascii char (x) QCMD Program to call 


x - up to a maximum of 10 characters 


In order to communicate the server random seed value to the client, 
the server will request a USERVAR name made up of a fixed part (the 8 
characters "IBMRSEED" immediately followed by an 8-byte hexadecimal 
variable part, which is the server random seed. The client generates 
its own 8-byte random seed value, and uses both seeds to encrypt the 
password. Both the encrypted password and the client random seed 
value are then sent to the server for authentication.  RFC 1572 rules 
will need to be adhered to when transmitting the client random seed 
and substituted password values to the server. Specifically, since a 
typical environment string is a variable length hexadecimal field, 
the hexadecimal fields are required to be escaped and/or byte stuffed 
according to the RFC 854 [8], where any single byte could be mis- 
construed as a Telnet IAC or other Telnet option negotiation control 
character. The client must escape and/or byte stuff any bytes which 
could be seen as a RFC 1572 [13] option, specifically VAR, VALUE, ESC 
and USERVAR. 
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The following illustrates the encrypted case: 


AS/400 Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON --> 

<-- TAC WILL NEW-ENVIRON 
TAC SB NEW-ENVIRON SEND 
USERVAR "IBMRSEEDXXXXXXXxx" 
USERVAR "IBMSUBSPW" 


VAR USERVAR IAC SE --» 
IAC SB NEW-ENVIRON IS 
VAR "USER" VALUE "DUMMYUSR" 
USERVAR "IBMRSEED" VALUE "yyyyyyyy" 
USERVAR "IBMSUBSPW" VALUE "zzzzzzzz" 
«-- IAC SE 


(other negotiations) 


In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 
seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed and 
"ZZZZZZzz" is an 8-byte hexadecimal encrypted password. If the 
password is not valid, then the sign-on panel is displayed. If the 
password is expired, then the Change Password panel is displayed. 


Actual bytes transmitted in the above example are shown in hex below, 
where the server seed is "7D3E488F18080404", the client seed is 
"4E4142334E414233" and the encrypted password is "DFB0402F22ABAS3BA". 
The user profile used to generate the encrypted password is 
"44554D4D59555352" (DUMMYUSR), with a clear-text password of 
"44554D4D595057" (DUMMYPW) . 


AS/400 Telnet server Enhanced Telnet client 


FF FA 27 00 00 55 53 45 
52 01 44 55 4D 4D 59 55 
53 52 03 49 42 4D 52 53 
45 45 44 01 4E 41 42 33 
4E 41 42 33 03 49 42 4D 
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53 55 42 53 50 57 01 DF 
BO 40 2F 22 AB A3 BA FF 
<-- FO 


The following illustrates the clear-text case: 


AS/400 Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON --> 
<-- TAC WILL NEW-ENVIRON 
TAC SB NEW-ENVIRON SEND 
USERVAR "IBMRSEEDXXXXXXXxx" 
USERVAR "IBMSUBSPW" 
VAR USERVAR IAC SE --> 
TAC SB NEW-ENVIRON IS 
VAR "USER" VALUE "DUMMYUSR" 
USERVAR "IBMRSEED" VALUE 
USERVAR "IBMSUBSPW" VALUE "yyyyyyyy" 
<-- TAC SE 


(other negotiations) 
In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 


seed, "yyyyyyyyyy" is a 10-byte us-ascii client clear-text password. 
If the password has expired, then the sign-on panel is displayed. 


Actual bytes transmitted in the above example are shown in hex below, 
where the server seed is "7D3E488F18080404", the client seed is empty 
and the clear-text password is "44554D4D595057" (DUMMYPW). The user 
profile used is "44554D4D59555352" (DUMMYUSR). 


AS/400 Telnet server Enhanced Telnet client 


FF FA 27 00 00 55 53 45 
52 01 44 55 4D 4D 59 55 
53 52 03 49 42 4D 52 53 
45 45 44 01 03 49 42 4D 
53 55 42 53 50 57 01 44 
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5.1 Password Substitutes Processing 


Both APPC and Client Access use well-known DES encryption algorithms 
to create encrypted passwords. A Network Station or Enhanced Client 
can generate compatible encrypted passwords if they follow these 
Steps, details of which can be found in the Federal Information 
Processing Standards 46-2 [17]. 


1. Padded PW = Left justified user password padded to the right with 
'40'X to 8 bytes. 


The users password must be left justified in an 8 byte variable 
and padded to the right with '40'X up to an 8 byte length. If the 
users password is 8 bytes in length, no padding would occur. For 
computing password substitutes for passwords of length 9 and 10 
see section "Handling passwords of length 9 and 10" below. 
Passwords less than 1 byte or greater than 10 bytes in length are 
not valid. Please note, if password is not in EBCDIC, it must be 
converted to EBCDIC uppercase. 


2. XOR PW = Padded PW xor '5555555555555555'X 
The padded password is Exclusive OR'ed with 8 bytes of '55'x. 
3. SHIFT RESULT = XOR PW << 1 


The entire 8 byte result is shifted 1 bit to the left; the 
leftmost bit value is discarded, and the rightmost bit value is 
cleared to O0. 


4. PW TOKEN = DES ECB mode(SHIFT RESULT, /* key */ 
userID in EBCDIC uppercase /* data */ ) 


This shifted result is used as key to the Data Encryption Standard 
(Federal Information Processing Standards 46-2 [17]) to encipher 
the user identifier. When the user identifier is less than 8 
bytes, it is left justified in an 8 byte variable and padded to 
the right with '40'X. When the user identifier is 9 or 10 bytes, 
it is first padded to the right with '40'X to a length of 10 
bytes. Then bytes 9 and 10 are "folded" into bytes 1-8 using the 
following algorithm: 


Bit 0 is the high-order bit (i.e. has value of '80'X). 


Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1 
Exclusive OR'ed with byte 9, bits 0 and 1. 
Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1 
Exclusive OR'ed with byte 9, bits 2 and 3. 
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Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1 
Exclusive OR'ed with byte 9, bits 4 and 5. 
Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1 
Exclusive OR'ed with byte 9, bits 6 and 7. 
Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1 
Exclusive OR'ed with byte 10, bits 0 and 1. 
Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1 
Exclusive OR'ed with byte 10, bits 2 and 3. 
Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1 
Exclusive OR'ed with byte 10, bits 4 and 5. 
Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1 
Exclusive OR'ed with byte 10, bits 6 and 7. 


User identifier greater than 10 bytes or less than 1 byte are not 
the result of this encryption id known as PW TOKEN in the paper. 


5. Increment PWSEQs and store it. 


Each LU must maintain a pair of sequence numbers for ATTACHs sent 
and received on each session. Each time an ATTACH is generated, 
(and password substitutes are in use on the session) the sending 
sequence number, PWSEQs, is incremented and saved for the next 
time. Both values are set to zero at BIND time. So the first use 
of PWSEQs has the value of 1, and increases by one with each use. 
A new field is added to the ATTACH to carry this sequence number. 
However, in certain error conditions, it is possible for the 
sending side to increment the sequence number and the receiver may 
not increment it. When the sender sends a subsequent ATTACH, the 
receiver will detect a missing sequence. This is allowed. 

However the sequence number received must always be larger than 
the previous one, even if some are missing. 


The maximum number of consecutive missing sequence numbers allowed 
is 16. If this is exceeded, the session is unbound with a 
protocol violation. 


Note: The sequence number must be incremented for every ATTACH 


sent. However, the sequence number field is only required to be 
included in the FMH5 if a password substitute is sent (byte 4, bit 
3- on) 


6. RDrSEQ = RDr + PWSEQs  /* RDr is server seed. */ 


The current value of PWSEQs is added to RDr, the random value 
received from the partner LU on this session, yielding RDrSEQ, 
essentially a predictably modified value of the random value 
received from the partner LU at BIND time. 
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7. PW SUB = DES. CBC. mode (PW TOKEN, /* key */ 
(RDrSEQ, /* 8 bytes */ 
RDs, /* 8 bytes */ 
ID xor RDrSEQ, /* 16 bytes */ 
PWSEQs, /* 8 bytes */ 
) /* data */ 


) 


The PW TOKEN is used as a key to the DES function to generate 
a 8 bytes value for the following string of inputs. The DES 
CBC mode Initialization Vector (IV) used is 8 bytes of '00'X. 


RDrSEQ: the random data value received from the partner LU 
plus the sequence number. 


RDs: the random data value sent to the partner LU on BIND 


for this session. 
A 16 byte value created by: 


- padding the user identifier with '40'X to a 
length of 16 bytes. 


- Exclusive OR the two 8 byte halves of the padded 
user identifier with the RDrSEQ value. 


Note: User ID must first be converted to EBCDIC 
upper case. 


PWSEQs: the sequence number. 
This is similar to the process used on LU-LU verification as 
described in the Enhanced LU-LU Bind Security. The resulting 


enciphered random data is the 'password substitute'. 


5.2 Handling passwords of length 9 and 10 


1. Generate PW TOKENa by using characters 1 to 8 of the password and 


steps 1-4 from the previous section. 


2. Generate PW TOKENb by using characters 9 and 10 and steps 1-4 from 
the previous section. In this case Padded PW from step 1 will be 
characters 9 and 10 padded to the right with '40'X, for a total 


length of 8. 


3. PW TOKEN = PW TOKENa xor PW TOKENb 
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4. Now compute PW SUB by performing steps 5-7 from the previous 
section. 


5.3 Example Password Substitute Calculation 


ID: USER123 

Password: ABCDEFG 

Server seed:  '7D4C2319F28004B2'X 

Client seed:  '08BEF662D851FA4B1'X 

PWSEQs: 1 (PWSEQs is a sequence number needed in the 
7-step encryption, and it is always one) 


Encrypted Password should be : ’ 5A58BD50E4DD9B5F’X 
6. Device Name Collision Processing 


Device name collision occurs when a Telnet client sends the Telnet 
Server a virtual device name that it wants to use, but that device is 
already in use on the server. When this occurs, the Telnet server 
sends a request to the client asking it to try another device name. 
The environment option negotiation uses the USERVAR name of DEVNAME 
to communicate the virtual device name. The following shows how the 
Telnet server will request the Telnet client to send a different 
DEVNAME when device name collision occurs. 


AS/400 Telnet server Enhanced Telnet client 


IAC SB NEW-ENVIRON SEND 
VAR USERVAR IAC SE --» 


Server requests all environment variables be sent. 
IAC SB NEW-ENVIRON IS USERVAR 
"DEVNAME" VALUE "MYDEVICEI" 
USERVAR "Xxxxx" VALUE "xxx" 


<> IAC SE 


Client sends all environment variables, including DEVNAME. Server 
tries to select device MYDEVICE1. If the device is already in use, 


server requests DEVNAME be sent again. 


IAC SB NEW-ENVIRON SEND 
USERVAR "DEVNAME" IAC SE -—» 
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Server sends a request for a single environment variable: 


Client sends one environment variable, 


MYDEVICE2. 
client. 


not in use, 


or the same 
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DEVNAME 


IAC SB NEW-ENVIRON IS USERVAR 


"DEVNAME" 


VALUE 


"MYDEVICE2" IAC SE 


calculating a new value of 
If MYDEVICE2 is different from the last request, 
Server tries to select device MYDEVICE2, 
If MYDEVICE2 is also in use, 
request again, 


then 


else server disconnects 
server will send DEVNAME 


and keep doing so until it receives a device that is 


device name 


7. Enhanced Printer Emulation Support 


twice in row. 


RFC 1572 style USERVAR variables have been defined to allow a 
compliant Telnet client more control over the Telnet server virtual 


device on the AS/400. 


These USERVAR's allow the client Telnet to 


select a previously created virtual device or auto-create a new 
virtual device with requested attributes. 


This makes the enhancements available to 


chonoses to support the new negotiations. 


The USERVAR's defined to accomplish this 


are: 
EXAMPLE 


PRINTERI 

242450 

QSYSOPR 

OSYS 

12 

pv m 

1 | 0 
*IBMA2023 

1-byte hex field 
1-byte hex field 
1-byte hex field 
Te Ire 

*NONE 

*LIBL 


USERVAR VALUE 

DEVNAME us-ascii char (x) 
IBMIGCFEAT us-ascii char (6) 
IBMMSGQNAME us-ascii char (x) 
IBMMSGOLIB us-ascii char (x) 
IBMFONT us-ascii char (x) 
IBMFORMFEED us-ascii char (1) 
IBMTRANSFORM us-ascii char (1) 
IBMMFRTYPMDL us-ascii char (x) 
IBMPPRSRC1 binary (1) 
IBMPPRSRC2 binary (1) 
IBMENVELOPE binary (1) 
IBMASCII899 us-ascii char (1) 
IBMWSCSTNAME us-ascii char (x) 
IBMWSCSTLIB us-ascii char (x) 
x - up to a maximum of 


10 characters 


any Telnet client that 


DESCRIPTION 
Printer device name 
IGC feature (DBCS) 
*MSGO name 

*MSGO library 

Font 

Formfeed 

Transform 

Mfg. type and model 
Paper source 1 
Paper source 2 
Envelope hopper 
ASCII 899 support 
WSCST name 

WSCST library 


The "IBM" prefix on the USERVAR's denotes AS/400 specific attributes. 


The DEVNAME USERVAR is used both for displays and printers. 


The 


IBMFONT and IBMASCII899 are used only for SBCS environments. 
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For a description of most of these parameters (drop the 


the USERVAR) 


and their permissible values, 
Communications Configuration Reference 


[5]. 


July 2000 


"IBM" from 
refer to Chapter 8 in the 


The IBMIGCFEAT supports the following variable DBCS language 


identifiers in position 5 
must be '0'): 


'g' 
"C! = 


Japanese 
Traditional Chinese 


^K 


(positions 1-4 must be '2424', 


Korean 
'S' = Simplified Chinese 


The IBMTRANSFORM and IBMASCII899 values correspond to: 


117 = 


Yes 


ED 


No 


The IBMFORMFEED values correspond to: 


‘Cc’ = 


The IBMPPRSRCI, 


Continuous 


"Ur = Cut 


"A! = 


Autocut 


position 6 


IBMPPRSRC2 and IBMENVELOPE custom USERVAR’s do not 


map directly to their descriptions in Chapter 8 in the Communications 
use the index listed 


Configuration Reference [5]. 


To map these, 


here: 

IBMPPRSRC1 HEX IBMPPRSRC2 HEX IBMENVELOPE HEX 
*NONE 'FFE'X *NONE / FF'X * NONE /FF'X 
*MFRTYPMDL 7 00' X *MFRTYPMDL '00'X *MFRTYPMDL '00'X 
*LETTER '01'X *LETTER '01'X *B5 '06'X 
*LEGAL '02'X *LEGAL '02'X *MONARCH '09'x 
*EXECUTIVE '03'X *EXECUTIVE '03'X *NUMBER9 'QA'X 
*A4 7 04'X *A4 7 04'X * NUMBER10 'OB'X 
*AS 05/X *AS 7057 X *C5 'Q0C'X 
*BS '06'X *BS '06'X *DL 7 OD' X 
*CONT80 '07'X *CONT80 '07'X 

*CONT132 '08'X *CONT132 '08'X 

*A3 7 0E' X *A3 7 0E' X 

*B4 7 OF'X *B4 7 OF'X 

* LEDGER 710" X * LEDGER 710" X 


Note 1: For IBMPPRSRC2, *CONT80 and *CONT132 support starts at V3R7. 


Note 2: For IBMPPRSRC1 and IBMPPRSRC2, *A3, *B4 and *LEDGER support 
starts at V3R7. 
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8. 


Telnet Printer Terminal Types 


New Telnet options are defined for the printer pass-through mode of 
operation. To enable printer pass-through mode, both the client and 
Server must agree to at least support the Transmit-Binary, End-Of- 
Record, and Terminal-Type Telnet options. The following are new 
terminal types for printers: 


TERMINAL-TYPE DESCRIPTION 
IBM-5553-B01 Double-Byte printer 
IBM-3812-1 Single-Byte printer 


Specific characteristics of the IBM-5553-B01 or IBM-3812-1 printers 
are specified through the USERVAR IBMMFRTYPMDL, which specifies the 
manufacturer type and model. 


An example of a typical negotiation process to establish printer 
pass-through mode of operation is shown below. In this example, the 
server initiates the negotiation by sending the DO TERMINAL-TYPE 
request. 


For DBCS environments, if IBMTRANSFORM is set to 1 (use Host Print 
Transform), then the virtual device created is 3812, not 5553. 
Therefore, IBM-3812-1 should be negotiated for TERMINAL-TYPE, and not 
IBM-5553-B01. 


AS/400 Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON --> 
<-- TAC WILL NEW-ENVIRON 
TAC SB NEW-ENVIRON SEND 
VAR USERVAR IAC SE --> 
TAC SB NEW-ENVIRON IS 
USERVAR "DEVNAME" VALUE "PCPRINTER" 
USERVAR "IBMMSGONAME" VALUE "QSYSOPR" 
USERVAR "IBMMSGOLIB" VALUE "*LIBL" 
USERVAR "IBMTRANSFORM" VALUE "OQ" 
USERVAR "IBMFONT" VALUE "12" 
USERVAR "IBMFORMFEED" VALUE "C" 
USERVAR "IBMPPRSRC1" VALUE ESC ’01’X 
USERVAR "IBMPPRSRC2" VALUE '04'X 
USERVAR "IBMENVELOPE" VALUE IAC 'FF'X 
<-- TAC SE 
TAC DO TERMINAL-TYPE --> 
<-- TAC WILL TERMINAL-TYPE 


IAC SB TERMINAL-TYPE SEND 
IAC SE --» 
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IAC DO BINARY 


IAC DO EOR 


Some points about the above example. 
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IAC SB TERMINAL-TYPE IS IBM-3812-1 


<-- IAC SE 

--» 

<-- IAC WILL BINARY 
--» 

<-- IAC WILL EOR 


escaping the value using ESC according to RFC 1572 
IBMPPRSRC2 does not require an ESC character since '04'X has no 
conflict with RFC 1572 options. Finally, to send 'FF'X for the 
escape the 'FF'X value by using another 'FF'X 


IBMENVELOPE value, 
(called "doubling"), 


[13]. 


The IBMPPRSRC1 value requires 


The 


SO as not to have the value interpreted as a 


Telnet character per RFC 854 [8]. 


Actual bytes transmitted in the above example are shown in hex below. 


AS/400 Telnet server 


FF FD 27 


FF FA 27 01 00 03 FF FO --» 


FF FD 18 


FF FA 18 01 FF F0 


FF FD 


FF FD 


Murphy, 


00 
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FF FA 18 00 
<==. 33 38 31 32 


Informational 


49 
2D 


42 
31 


4D 
FF 


Enhanced Telnet client 


2D 
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FF FB 19 
9. Telnet Printer Startup Response Record for Printer Emulators 


Once Telnet negotiation for a 5250 pass-through mode is completed, 
the 5250 Telnet server will initiate a virtual printer power-on 
sequence on behalf of the Telnet client. The Telnet server will 
supply a Startup Response Record to the Telnet client with the status 
of the printer power-on sequence, indicating success or failure of 
the virtual printer power-on sequence. 


This section shows an example of two Startup Response Records. The 
Source device is a type 3812 model 01 printer with name "PCPRINTER" 
on the target system "TARGET". 


Figure 1 shows an example of a successful response; Figure 2 shows an 
example of an error response. 


9.1 Example of a Success Response Record 
The response record in Figure 1 was sent by an AS/400 at Release 


V4R2. It is an example of the target sending back a successful 
Startup Response Record. 


4------------------------------------------------------------------ + 
+----- Pass-Through header 
| +--- Response data 
| +---- Start diagnostic information 
4---------- 44---------- 44--------------------------------------- 


| | TARGET PCPR 


Response Code (1902) 


C9D5E3C5D9400000000000000000000000000000000000000000000000000000 


+ 
l 
l 
l 
l 
+ 


INTER 
+------- End of diagnostic information 
je KS ee ee eee + 
| 
| 000000000000000000 
$-------------- - - 5 + 


Figure 1. Example of a success response record. 
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- '0049'X = Length pass-through data, including this length field 
'12A0'X = GDS LU6.2 header 

'90000560060020C0003D0000'X = Fixed value fields 

- 'C9F9F0F2'X Response Code (1902) 

— 'E3CID9C7C5E34040'X = System Name (TARGET) 
'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) 


9.2 Example of an Error Response Record 


The response record in Figure 2 is one that reports an error. The 
virtual device named "PCPRINTER", is not available on the target 
system "TARGET", because the device is not available. You would 
normally see this error if the printer was already assigned to 
another Telnet session. 


4---------------------------------------------2--------------------- - 
T----- Pass-Through header 
| +--- Response data 
| | a Start diagnostic information| 


| | TARGET PCPR 


004912A09000056006008200003D0000F8F9F0F2E3C1D9C7C5E34040D7C3D7D9 | 
| 

| 

Response Code (8902) | 


C9D5E3C5D9400000000000000000000000000000000000000000000000000000 


| 
INTER | 
| 
d--———-- End of diagnostic information 
| 
——À—À—————— —— P T 
| | 
| 000000000000000000 | 
o a SSS SS ae eS SS SS Sa Se aS Se Se ases + 


Figure 2. Example of an error response record. 


- '0049'X = Length pass-through data, including this length field 
'12A0'X = GDS LU6.2 header 

7 90000560060020C0003D0000' X Fixed value fields 

- 'F8F9FOF2'X = Response Code (8902) 

— 'E3CID9C7C5E34040'X System Name (TARGET) 
'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) 
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9.3 Response Codes 


The Start-Up Response Record success response codes: 


CODE 
1901 
1902 
1906 


DESCRIPTION 


Virtual device has less function than source device 
Session successfully started 

Automatic sign-on reguested, but not allowed. 
Session still allowed; a sign-on screen will be 
coming. 


The Start-Up Response Record error response codes: 


CODE 
2102 
2703 
2777 
8901 
8902 
8903 
8906 
8907 
8910 
8916 
8917 
8918 
8920 
8921 
8922 
8923 
8925 
8928 
8929 
8930 
8934 
8935 
8936 
8937 
8940 
1904 


Murphy, 


DESCRIPTION 


Device description not found. 
Controller description not found. 
Damaged device description. 

Device not varied on. 

Device not available. 

Device not valid for session. 
Session initiation failed. 

Session failure. 

Controller not valid for session. 

No matching device found. 

Not authorized to object. 

Job canceled. 

Object partially damaged. 
Communications error. 

Negative response received. 

Start-up record built incorrectly. 
Creation of device failed. 

Change of device failed. 

Vary on or vary off failed. 

Message gueue does not exist. 
Start-up for S/36 WSF received. 
Session rejected. 

Security failure on session attempt. 
Automatic sign-on rejected. 
Automatic configuration failed or not allowed. 
Source system at incompatible release. 
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10. Printer Steady-State Pass-Through Interface 
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The information in this section applies to the passthrough session 
after the receipt of startup confirmation records is complete. 


Following is the printer header interface used by Telnet. 


T— 
| 


+-- Length of structure (LLLL) 


+-- GDS identifier 


t-- Data flow record 


t-- Length of pass-through specific header (LL) 


t-- Flags 


t-- Printer operation code 


-+ +--+ +--+ ++ +--+ ++ 4---------- + 


+-- Printer data 


t-- Diagnostic field - zero pad to 
LL specified 


print data 


4------------------------------------------------------------------ t 

Figure 3. Layout of the printer pass-through header 

BYTES 0-1: Length of structure including this field (LLLL) 

BYTES 2-3: GDS Identifier ('12A0'X) 

BYTE 4-5: Data flow record 
This field contains flags that describe what type of 
data pass-through should expect to find following this 
header. Generally, bits 0-2 in the first byte are 
mutually exclusive (that is, if one of them is set to ' 
1'B, the rest will be set to ’0’B.) The bits, and their 
meanings follow. 
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BYTE 


BYTES 


6: 


7-8: 
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BIT DESCRIPTION 


Start-Up confirmation 

Termination record 

Start-Up Record 

Diagnostic information included 

Reserved 

Reserved 

Printer record 

ees. Reserved 

4 Client-originated (inbound) printer record 
5 Server-originated (outbound) printer record 


PrROoONADADABWNERO 
| 
ol 


Length printer pass-through header including this 
field (LL) 


Flags 


BYTE 7 BITS: xxxx x111 --> Reserved 


XXXX lxxx --> Last of chain 

xxxl xxxx --> First of chain 

xx1x xxxx --> Printer now ready 
x1lxx xxxx --> Intervention Required 
1xxx xxxx --> Error Indicator 


BYTE 8 BITS:  xxxx xxxx --> Reserved 


BYTE 


BYTE 


If 


If 


If 


Murphy, 


9s Printer operation code 
/01'X Print/Print complete 
'02'X Clear Print Buffers 
10-LL: Diagnostic information (1) 
BYTE 7 = xxlx xxxx then bytes 10-LL may contain: 
Printer ready C9 00 00 00 02 
BYTE 7 = xlxx xxxx then bytes 10-LL may contain: (2) 


Command/parameter not valid C9 00 03 02 2x 


Print check C9- 00 03:102. 3x 
Forms check C9 00 03 02 4x 
Normal periodic condition C9 00 03 02 5x 
Data stream error C9 00 03 02 6x 


Machine/print/ribbon check C9 00 03 02 8x 


BYTE 7 = lxxx xxxx then bytes 10-LL may contain: (3) 

Cancel 08 11 02 00 

Invalid print parameter 08 11 02 29 
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Invalid print command 08 11 02 28 
Diagnostic information notes: 
1. LL is the length of the structure defined in Byte 6. If no 


additional data is present, the remainder of the structure must 
be padded with zeroes. 


2. These are printer SIGNAL commands. Further information on these 
commands may be obtained from the 5494 Remote Control Unit 
Functions Reference guide [2]. Refer to your AS/400 printer 
documentation for more specific information on these data stream 
exceptions. Some 3812 and 5553 errors that may be seen: 

Machine check C9 00 03 02 11 
Graphics check C9 00 03 02 26 
Print check C9. 00 03 02 31 
Form jam C9 00 03 02 41 
Paper jam C9 00 03 02 47 
End of forms C9 00 03 02 50 
Printer not ready C9 00 03 02 51 
Data stream - class 1 C9 00 03 02 66 loss of text 
Data stream - class 2 C9 00 03 02 67 text appearance 
Data stream - class 3 C9 00 03 02 68 multibyte control error 
Data stream - class 4 C9 00 03 02 69 multibyte control parm 
Cover unexpectedly open C9 00 03 02 81 
Machine check C9 00 03 02 86 
Machine check C9 0003 02 87 
Ribbon check C9 00 03 02 88 
3. These are printer negative responses. Further information on 


these commands may be obtained from the 5494 Remote Control Unit 
Functions Reference guide [2]. 


The print data will start in byte LL-*1. 
10.1 Example of a Print Record 
Figure 4 shows the server sending the client data with a print 


record. This is normally seen following receipt of a Success 
Response Record, such as the example in Figure 1. 
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*-- Length of structure (LLLL) | 

*-- GDS identifier | 
| +-- Data flow record 

| +-- Length of pass-through specific header (LL) | 

| | +-- Flags | 

| 

| 


| | | | *-- Zero pad to LL specified (0A) 
*-- Printer data 


+--+ +--+ +--+ ++ +--+ ++ 4---------- + $--------------------------- 


0085 12A0 0101 OA 1800 01 000000000000 34C4012BD20345FF2BD2044C0002 | 


| 
| 
| | | | +-- Printer operation code 
| 


2BD10705000B0090012BD2044900F02BD206404A403DE02BD2041500F034 


end of printer data 


Figure 4. Server sending client data with a print record 


- '0085'X = Logical record length, including this byte (LLLL) 
- '12A0'X = GDS LU6.2 header 

- '0101'X = Data flow record (server to client) 

— 'ÜOA'X = Length of pass-through specific header (LL) 

- '1800'X = First of chain / Last of chain indicators 

= '01'X = Print 

— '000000000000’X = Zero pad header to LL specified 

— '34CA401'X = First piece of data for spooled data 


- Remainder is printer data/commands/orders 
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10.2 Example of a Print Complete Record 


Figure 5 shows the client sending the server a print complete record. 
This would normally follow receipt of a print record, such as the 


example in Figure 4. This indicates successful completion of a print 
request. 
4-——----------------------------------------------------------------- t 


t-- Length of structure (LLLL) 

| +-- GDS identifier 

| | +-- Data flow record 

| | | +-- Length of pass-through specific header (LL) 
| 

| 


| | | +-- Flags 
| | | | +-- Printer operation code 


+--+ +--+ +--+ ++ +--+ ++ 


| 000A 12A0 0102 04 0000 01 


Figure 5. Client sending server a print complete record 


— '000A'X = Logical record length, including this byte (LLLL) 
- '12A0'X = GDS LU6.2 header 

- '0102'X Data flow response record (client to server) 

- '04'X Length of pass-through specific header (LL) 

- '0000'X = Good Response 

— ’01’X = Print Complete 


10.3 Example of a Null Print Record 


Figure 6 shows the server sending the client a null print record. 
The null print record is the last print command the server sends to 
the client for a print job, and indicates to the printer there is no 
more data. The null data byte '00'X is optional, and in some cases 
may be omitted (in particular, this scenario occurs in DBCS print 
streams). 


This example would normally follow any number of print records, such 
as the example in Figure 4. This indicates successful completion of 
a print job. The client normally responds to this null print record 
with another print complete record, such as in Figure 5. 
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t-- Length of structure (LLLL) 

+-- GDS identifier 

| +-- Data flow record 

| | +-- Length of pass-through specific header (LL) 
| | | +-- Flags 

| | | | +-- Printer operation code 

| | | | | +-- Zero pad to LL specified (0A) 
| | +-- Printer data 


ot +--+ +--+ ++ +--+ ++ 4---------- + ++ 


011 12A0 0101 0A 0800 01 000000000000 00 


o—+ 


Figure 6. Server sending client a null print record 


= '0011'X = Logical record length, including this byte 
- '12A0'X = GDS LU6.2 header 

- '0101'X = Data flow record 

— 'ÜOA'X = Length of pass-through specific header (LL) 
- '0800'X = Last of Chain 

=? OTAK = Print 

- '000000000000'X = Zero pad header to LL specified 

- '00'X = Null data byte 


11. End-to-End Print Example 


The next example shows a full print exchange between a Telnet client 
and server for a 526 byte spooled file. Selective translation of the 
hexadecimal streams into 1) Telnet negotiations and 2) ASCII/EBCDIC 
characters are done to aid readability. Telnet negotiations are 
delimited by '(' and ')' parenthesis characters; ASCII/EBCDIC 
conversions are bracketed by '|' vertical bar characters. 


AS/400 Telnet server Enhanced Telnet client 


FFFD27 --» 


(IAC DO NEW-ENVIRON) 
«-- FFFB27 


(IAC WILL NEW-ENVIRON) 


FFFD18FFFA270103 49424D5253454544 
7EA5DFDDFD300404 0003FFF0 --» 


(IAC DO TERMINAL-TYPE 
IAC SB NEW-ENVIRON SEND USERVAR 
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IBMRSEED xxxxxxxx VAR USERVAR 


IAC SE) 


FFFA180 


1FFFO 


<-- 


(IAC SB TERMINAL-TYPE SEND IAC 


SE) 


<-- 


FFFB18 


July 2000 


(IAC WILL TERMINAL-TYPE) 


FFFA27000349424D 
DDFD300404000344 
554D4D5950525403 
414D450151535953 
5347514C4942012A 
464F4E5401313103 
464F524D01310349 
4D444C012A485049 
5352433101020103 
433201040349424D 
O1LFFFF0349424D41 
30FFFO 


52534545447EA5DF 
45564E414D450144 
49424D4D5347514E 
4F50520349424D4D 
4C49424C0349424D 
49424D5452414E53 
424D4D4652545950 
490349424D505052 
49424D5050525352 
454E56454C4F5045 
5343494938393901 


(IAC SB NEW-ENVIRON IS USERVAR 


IBMRSEED xxxxxxxx VAR 

USERVAR DEVNAME VALUE DUMMYPRT 
USERVAR IBMMSGQNAME VALUE QSYSOPR 
USERVAR IBMMSGQLIB VALUE *LIBL 
USERVAR IBMFONT VALUE 11 

USERVAR IBMTRANSFORM VALUE 1 
USERVAR IBMMFRTYPMDL VALUE *HPII 
USERVAR IBMPPRSRC1 VALUE ESC ’01’X 
USERVAR IBMPPRSRC2 VALUE '04'X 
USERVAR IBMENVELOPE VALUE IAC 
USERVAR IBMASCII899 VALUE 0 

IAC SE) 


<-- FFFA180049424D2D 333831322D31FFF0 


(IAC SB TERMINAL-TYPE IS 
IBM-3812-1 IAC SE) 
FFFD19 Lob 


(IAC DO EOR) 
«-- FFFB19 
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(IAC WILL EOR) 
FFFB19 --> 
(IAC WILL EOR) 
<-- FFFD19 
(IAC DO EOR) 
FFFDOO --> 
(IAC DO BINARY) 
<-- FFFBOO 
(IAC WILL BINARY) 
FFFBOO --> 
(IAC WILL BINARY) 
<-- FFFDOO 
(IAC DO BINARY) 
004912A090000560 060020C0003D0000 - { 
C9F9FOF2C5D3C3D9 E3D7FOF6C4E4D4D4 I902ELCRTPO6DUMM (EBCDIC) 
E8D7D9E340400000 0000000000000000 | YPRT 
0000000000000000 0000000000000000 | 
0000000000000000 OOFFEF --» | 
(73-byte startup success response 
record IAC EOR) 
00DF12A001010A18 0001000000000000 | 
03CD1B451B283130 551B287330703130 | E (10U (s0p10| (ASCII) 
2E30306831327630 733062303033541B [.00h12v0s05003T | 
287330421B266440 1B266C304F1B266C |(sOB &d@ &100 &l| 
303038431B266C30 3035431B28733070 008C &1005C (sOp 
31372E3130683130 7630733062303030 17.10h10v0s0b000 
541B283130551B28 73307031372E3130 [T (10U (s0p17.10| 
6831307630733062 303030541B287330 [h10v0s0b000T (s0| 
421B2664401B266C 314F1B266C303035 |B &d@ &110 &1005| 
431B287330703137 2E31306831307630 [C (s0p17.10h10v0| 
733062303030541B 266C314F1B287330 s0b000T 8110 (sO 
7031372E31306831 3076307330623030 p17.10h10v0s0b00 
30541B2873307031 372E313068313076 [OT (s0p17.10h10v | 
3073306230303054 1B266C30303543FF [0s0b000T &1005C | 
EF --» | | 
(... 223-byte print record 
first of chain 
last of chain IAC EOR) 
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«-- 000A12A001020400 0001FFEF 


10-byte print complete header) 


( 
031012A001010A10 0001000000000000 | 
O3FFFF1B451B2831 30551B2873307031 | E (10U (s0p1| 
372E313068313076 3073306230303054 |7.10h10v0s0b000T | 
1B287330421B2664 401B266C314F1B26 | (SOB &d@ &110 &| 
6C303035431B266C 31481B266C314F1B [1005C &11H &110 | 
266C3032411B266C 31431B266C303030 EE &11C d 
38451B266C303038 431B266C30303439 8E &1008C &10049 
461B266130521B26 6C303035430A0A0A |F &a0R &1005C | 
0A0A0A0A1B26612B 3030303130561B26 | &a+00010V &| 
6C303035431B2661 2B30303231364820 | 1005C &a+00216H | 
2020202020202020 2020202020202020 | 
2020202020205072 696E74204B657920 | Print Key | 
4F75747075742020 2020202020202020 Output 
2020202020202020 2020202020202020 
2020202020205061 6765202020310D0A | Page iy | 
1B26612B30303231 3648202020203537 | &a+00216H 57 | 
3639535331205634 52334D3020393830 |69SS1 V4R3M0 980| 
373203FFFF392020 2020202020202020 |72 9 
202020202020454C 4352545030362020 ELCRTP06 
2020202020202020 202030332F33312F 03/31/ 
3939202031363A33 303A34350D0A1B26 [99 16:30:45 &| 
612B303032313648 0D0A1B26612B3030 |a+00216H . &a*00| 
3231364820202020 446973706C617920 |216H Display | 
4465766963652020 2E202E202E202E20 [Device ; zll 
2E203A2020515041 444556303033510D l : OPADEVO030 | 
0A1B26612B303032 3136482020202055 £a+00216H U 
73657220202E202E 202E202E202E202E [ser E 
202E202E202E202E 203A202052434153 [linase xS "RCAS| 
54524F0D0A1B2661 2B3030323136480D | TRO '&a*00216H | 
0A1B26612B303032 313648204D41494E | &a+00216H MAIN| 
2020202020202020 2020202020202020 | 
2020202020202020 20202041532F3430 AS/40 
30204D61696E204D 656E750D0A1B2661 [0 Main Menu  &a| 
2B30303203FFFF31 3648202020202020 [4002 16H | 
2020202020202020 2020202020202020 | 
2020202020202020 2020202020202020 | 
2020202020202020 2020202020202020 | 
2020202020202053 797374656D3A2020 System: 
20454C4352545030 360D0A1B26612B30 | ELCRTPO6 &a+0| 
3032313648205365 6C656374206F6E65 [0216H Select one| 
206F662074686520 666F6C6C6F77696E | of the Toad 
673A0D0A1B26612B 3030323136480D0A lg: &a+00216H 
1B26612B30303231 3648202020202020 E £a+00216H 
312E205573657220 7461736B730D0A1B User tasks 
26612B3030323136 4820202020202032 | & a+00216H 2 | 
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2E204F6666696365 
1B26612B30303231 
3030323136482020 
696C65732C206C69 
20616EFFEF 
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207461736B730D0A 
36480D0A1B26612B 
20202020342E2046 
627261726965732C 


(... 784-byte print record 


first of chain 


020312A001010A00 
64206603FFFF6F6C 
612B303032313648 
3231364820202020 
6D756E6963617469 
2B3030323136480D 
3136482020202020 
6C656D2068616E64 
612B303032313648 
20446973706C6179 
0A1B26612B303032 
31302E20496E666F 
417373697374616E 
730D0A1B26612B30 
202031312E20436C 
6573732F34303020 
26612B3030323136 
303231364803ED20 
5369676E206F 6666 
323136480D0A1B26 
2053656C65637469 
6D6D616E640D0A1B 
48203D3D3D3E0DOA 
36480D0A1B26612B 
333D457869742020 
707420202046393D 
2020204631323D43 
4631333D496E666F 
417373697374616E 
3032313648204632 
697469616C206D65 
3030323136480D0A 
36480D0CFFEF 


(... 515-byte print record 


IAC EOR) 
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|. Office tasks | 


| &a+00216H  &a*| 
00216H 4. F 
iles, libraries, 

| an | 


July 2000 


IAC EOR) 
«-- 000A12A001020400 0001FFEF 

(10-byte print complete header) 
0001000000000000 | | 
646572730D0A1B26 ld f  olders  &| (ASCII) 
0D0A1B26612B3030 |a+00216H . &a*00| 
2020362E20436F6D 216H 6. Com 
6F6E730D0A1B2661 munications &a 
0A1B26612B303032 [400216H &at+002| 
20382E2050726F62 [16H 8. Prob| 
6C696E670D0A1B26 [lem handling &| 
202020202020392E |a+00216H 9. | 
2061206D656E750D | Display a menu 
3136482020202020 &a+00216H 
726D6174696F6E20 |10. Information | 
74206F7074696F6E [Assistant option| 
3032313648202020 [s | &a*00216H | 
69656E7420416363 | 11. Client Acc| 
7461736B730D0A1B ess/400 tasks 
480D0A1B26612B30 &a*00216H &at0 
2020202039302E20 |0216H 90. | 
0D0A182661283030 [Sign off | &a*00| 
612B303032313648 [216H &a+00216H| 
6F6E206F7220636F | Selection or co| 
26612B3030323136 mmand puoi 
1B26612B30303231 H ===>  &a*0021 
3030323136482046 [6H | &a*00216H F| 
2046343D50726F6D |3=Exit | F4-Prom| 
5265747269657665 |pt | F9-Retrieve| 
616E63656C202020 |  F12=Cancel 
726D6174696F6E20 F13=Information 
740D0A1B26612B30 Assistant &at0 
333D53657420696E |0216H F23-Set in| 
6E750D0A1B26612B |itial menu &at+| 
1B26612B30303231 [00216H &a+0021| 

| 6H | 
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«-- 000A12A001020400 0001FFEF 
(10-byte print complete header) 
001412A001010A00 0001000000000000 
03021B45FFEF | E | (ASCII) 


(ees 
IAC 


20-byte print record 
EOR) 
«-- 000A12A001020400 0001FFEF 


(10-byte print complete header) 


001112A001010A08 0001000000000000 
OOFFEF m 


(iss 


17-byte NULL print record 
last of chain ... IAC EOR) 
«-- 000A12A001020400 0001FFEF 


(10-byte print complete header) 


12. Authors' Note 


Discussion of this memo should occur in one of these mailing lists: 


TN3270E List (Roger Fajman raf@cu.nih.gov). Send subscription 
requests as e-mail with "subscribe tn3270e your full name" to 
listserv@list.nih.gov. 


Midrange-L List (David Gibbs david@midrange.com). Send 
subscription requests as email with "subscribe midrange-l 
your_internet_address" to majordomo@midrange.com. 


Telnet Working Group Mailing List: Send subscription requests as 
email with "subscribe telnet-ietf" to telnet-ietf- 
request@bsdi.com. 
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Security Considerations 
Security considerations of passwords are discussed in Section 6. 
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Relation to Other RFC's 


UPDATES 


This memo is an update to RFC 1205 [14], which describes the 5250 


Telnet Interface. This update enhances that description to 
include device negotiation as well as printer support. 


This memo makes use of RFC 1572 [13] to enhance communications 


with 5250 Telnet clients. RFC 1572 is currently on the Standards 


Track as a Proposed Standard, and is listed in Assigned Numbers 
[19]. 
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17. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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